A network storage controller is a processing system that is used to store and retrieve data on behalf of one or more hosts on a network. A storage controller operates on behalf of one or more hosts to store and manage data in a set of mass storage devices, e.g., magnetic or optical storage-based disks, solid-state drives, or tapes. Some storage controllers are designed to service file-level requests from hosts, as is commonly the case with file servers used in network attached storage (NAS) environments. Other storage controllers are designed to service block-level requests from hosts, as with storage controllers used in a storage area network (SAN) environment.
Still other storage controllers are capable of servicing both file-level requests and block-level requests, as is the case with various storage controllers made by NetApp, Inc. of Sunnyvale, Calif.
A function commonly employed by storage controllers is the initialization of the storage subsystem. In some implementations, storage controllers can make some or all of the storage space on the drive(s) of a storage subsystem available to client systems once the drives are properly initialized. For example, each of the drive scan be implemented as an individual drive, multiple drives (e.g., a RAID group) or mass storage device(s). Storage of information in a mass storage subsystems can be implemented as one or more storage volumes that comprise a collection of physical storage drives (e.g., disks) cooperating to define an overall logical arrangement of volume block number (VBN) space on the volume(s). Each logical volume is generally, although not necessarily, associated with its own file system.
The drives within a logical volume/file system can be organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Drives (RAID). Most RAID implementations, e.g., a RAID-6 level implementation, enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical drives in the RAID group, and the appropriate storing of parity information with respect to the striped data. However, the RAID volumes must be initialized, for example, using an Immediate Available Format (IAF) background initialization process. The IAF background initialization process ensures consistent parity across the RAID volumes prior to (or simultaneously with) use (e.g., reads or writes) by the client systems by reading data in the uninitialized regions (e.g., the striped data), calculating the parity information, and storing the calculated parity information on the appropriate physical disks in the RAID group.
With the introduction of Protection Information (PI) enabled RAID volumes, the IAF process must ensure that all of the blocks on the physical drives contain the correct PI. The PI information typically includes a reference tag field that indicates logical blocks addresses which, in some configurations (e.g., RAID volumes with type-1 protection), are not contiguous between stripe segments on a drive. In these configurations, the IAF background initialization procedure is limited to an Input/Output “I/O” size of a single stripe segment as the PI is inserted sequentially in the drive channel. Consequently, the introduction of PI-enabled RAID volumes prevents the background initialization procedure from reading and/or writing large chunks of data to insert and/or verify the protection information.
Unfortunately, because the IAF procedure is limited to an I/O size of a single stripe segment, the IAF background initialization procedure can take on the order of multiple months or longer to initialize large storage systems. This problem can be due to excessive drive head movement at a disk array of the storage subsystem. Furthermore, during the background initialization process, performance of host I/O to initialized regions is seriously degraded.